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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document describes the II interface between IMS Centralized Services (ICS) UE and Service Centralization 
and Continuity (SCC) Application Server (AS). 

This specification defines a new application layer protocol over II interface, specifies the interaction between the ICS 
UE and the SCC AS including session control procedures and supplementary services control procedures. 

The protocol is intended to be independent of the transport protocol used so it can be applied to a number of 
technologies that need different transport protocols. 

The overall ICS architecture is specified in 3GPP TS 23.292 [2]. 

The present document is applicable to User Equipment (UE) and Application Servers (AS) which are intended to 
support the IMS centralized services. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 23.292: "IP Multimedia Subsystem (IMS) Centralized Services; Stage 2". 

[3] 3GPP TS 24.008: "Mobile radio interface layer 3 specification; Core Network protocols; Stage 3". 

[4] 3GPP TS 24.090: "Unstructured Supplementary Service Data; Stage 3". 

[5] 3GPP TS 24.292: " IP Multimedia (IM) Core Network (CN) subsystem Centralized Services 

(ICS); Stage 3". 

[6] RFC 3261 (June 2002): "SIP: Session Initiation Protocol". 

[7] 3GPP TS 23.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 2". 



Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 
3GPPTR 21.905 [1]. 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.292 [2] apply: 

ICSUE 

SCC AS 
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For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.237 [7] apply 

Access Transfer 

Remote Leg 

Service Control Signalling Path 

Session Transfer 

Session Transfer Identifier (STI) 

Source Access Leg 

Target Access Leg 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 24.292 [5] apply: 

PSIDN 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPPTR 21.905 [1]. 

ICS IMS CentraHzed Services 

sec AS Service Centralization and Continuity Application Server 

STI Session Transfer Identifier 

USSD Unstructured Supplementary Service Data 



General description 



4.1 General 

For the current version of the specification the application layer protocol is run over Unstructured Supplementary 
Service Data (USSD) transport as defined in 3GPP TS 24.090 [4], however the application layer protocol is not 
restricted to USSD transport. 

4.2 Structure of the protocol 

4.2.1 Introduction 

The II protocol is a message based point to point protocol. The II protocol messages are transported within a point-to- 
point transport layer connection protocol and are exchanged between the ICS UE and SCC AS. 

The II protocol is a transport-independent protocol, i.e. the II protocol call control entities can exchange the II protocol 
messages over any transport-layer connection that connects the ICS UE and the SCC AS. 

The Ilprotocol's notation maintains a format of two parts, i.e. II message common part and II information elements. 
The II message common part is included in every II message. The II information elements those are included in an II 
message depend on a type of II message being sent. 

4.2.2 Application level protocol 

Overall descriptions with application level protocol are specified as following: 
1) it is used to access IMS services (e.g., IMS session origination); 
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2) it is a point to point protocol between the ICS UE and the SCC AS; 

3) its protocol does not support authentication; 

4) it does not support segmentation of messages; 

5) its messages are self-identifying; and 

6) it runs over any point-to-point transport-layer connection (e.g. USSD). 

4.2.3 Transport level protocols 

4.2.3.1 General 

The transport-layer connection that is used to transfer the II protocol messages is a bi-directional point-to-point 
connection between the ICS UE and the SCC AS. This transport-layer connection is a symmetric connection, i.e. the 
source-point on the transport-layer connection that is used to send the II protocol messages is also a destination-point 
for the incoming II protocol messages. 

4.2.3.2 USSD as transport level protocol 

The USSD provides a two-way-alternative interactive service (i.e.semiduplex) to the user. Only the entity (ICS UE or 
SCC AS) with the turn may send and its counterpart is permitted only to receive. II protocol control function (in ICS 
UE or SCC AS) has to buffer the II protocol message until it has the turn. 

Editor's Note: Exchanging a token if the II protocol is two sides interactive, in order to determine whether the UE or 
SCC AS can transmit one or more II messages may be a drain on the UE's battery. 

When USSD used as transport level protocol, overall descriptions are specified as following: 

1) the application level protocol messages shall be buffered until the USSD layer (in the ICS UE or CS network) 
gets the turn to send on the USSD connection; 

2) if the USSD connection still in maintenance and the USSD layer (in the ICS UE or CS network) hasn"t sent an 
application level protocol message for a specific time, an Il-Dummy message shall be delivered to the 
counterpart to transfer the turn with the consideration of not delaying its transmission of II protocol message; 
and 

Editor's Note: the need for a message transferring the turn (i.e. II Dummy message) is FES. 

3) if the II session is established, USSD connection will be released. 



5 Functional entities 

5.1 User Equipment (UE) 

To be compliant with this specification, a UE shall implement the role of ICS UE capabilities defined in 
subclauses 6.1.1, 6.2.1.2, 6.2.2.2, 6.2.3.2, 6.2.4.2. 6.2.5.2, 6.2.6.2, 7.5.3.2.1.1, and 7.5.3.2.2.1 



5.2 Application Server (AS) 



To be compliant with this specification, a AS shall implement the role of SCC AS capabilities defined in 
subclauses 6.1.2, 6.2.1.3, 6.2.2.3, 6.2.3.3, 6.2.4.3. 6.2.5.3, 6.2.6.3, 7.5.3.2.1.2, and 7.5.3.2.2.2. 
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6 Communication between ICS UE and SCC AS via 11 

interface 

6.1 Introduction 

The ICS UE and SCC AS use the II interface to setup, control, maintain and release an II session control channel and 
associated media over the CS bearer. 

6.2 Session control procedures 
6.2.1 Session setup 

6.2.1.1 General 

The ICS UE setups the session with CS media and the service control signalling via the II reference point. II is used to 
control services in the IM CN subsystem. 

II sessions can only be created by II session setup messages. An II Invite message is an II session setup message. II 
sessions can be torn down by II session release messages. An II BYE message is an II session release message. 

The following subclauses describe the procedures of the ICS UE and the SCC AS for session setup: 

subclause 6.2.1.2.1 describes the procedures of ICS UE session origination; 

subclause 6.2.1.2.2 describes the procedures of ICS UE session termination without UE assisted T-ADS 
function; 

subclause 6.2.1.2.3 describes the procedures of ICS UE session termination with UE assisted T-ADS function; 

subclause 6.2.1.3.1 describes the procedures of SCC AS session origination; 

subclause 6.2.1.3.2 describes the procedures of SCC AS session termination without UE assisted T-ADS 
function; and 

subclause 6.2.1.3.3 describes the procedures of SCC AS session termination with UE assisted T-ADS function. 

6.2.1 .2 Detailed behaviour of ICS UE 
6.2.1 .2.1 ICS UE CS Session Origination 

When the ICS UE originates a session using an Ilreference point, the UE shall: 
1) generate an II Invite message that includes: 

a) a Message type subfield set to the value that includes that this is an II Invite message; 

b) a new value in the Call-Identifier (Part-1) subfield, as specified in subclause 7.2.2. The Call-Identifier will 
uniquely identify this II session between the ICS UE and the SCC AS; 

Editor"s note: if forking is supported then such can have impact on the call-ID 

c) an allocated Message sequence number; 

d) a From-id information element that includes either a SIP URI or an E.164 number, and it will be used by the 
SCC AS to identify the ICS UE; 

Editor"s note: How to include the SIP URI into the II messages is FFS. 
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e) a To-id information element that includes either a SIP URI or an E. 164 number, and will be used by the SCC 
AS to determine the identity of the called user; 

f) a Privacy information element that indicates the ICS UE's privacy preferences. The SCC AS will apply these 
preferences to the SIP session that the SCC AS will establish on behalf of the UE; and 

g) a CS access network type indicator; and 

Editor's Note: It is FFS whether more items are needed. The ordering of the parameters and how they are coded is 
FFS. The transaction style is FFS. PUD naming is FFS. 

2) select the transport layer protocol depending on the access network type, and forward the II Invite message 
toward the SCC AS. 

When the UE receives an II Progress message with Progress reason set to Call progressing, the UE shall: 

1) save the received Call-Identifier value and use it for further reference to this session; 

2) verify if the message is in sequence according to the Message sequence number value, and save the received 
Message sequence number; 

3) store the SCC AS PSI DN value (i.e. the E.164 number) received in the SCC-AS-id information element; and 

4) store the STI value (i.e. the E.164 number) if received in the Session-identifier information element; 

NOTE 1: The STI value uniquely identifies the II session being established, and it may be subsequently used to 

refer to this II session, e.g. the SCC AS uses the STI to correlate the access transfer request received via 
the PS access with the active session established via the II interface. 

NOTE 2: The UE may indicate the Progress reason value to the user. 

Editor" s note: Responses indicating an error are FFS. 

Upon receiving the SCC AS PSI DN (i.e. the E.164 number) conveyed in the II Progress message with Progress reason 
set to Call progressing from the SCC AS, the ICS UE shall initiates the call over the CS domain by sending a SETUP 
message to the MSC Server as specified in 3GPP TS 24.008 [3] as follows: 

1) the Called Party BCD Number information element is set to the SCC AS PSI DN (i.e. the E. 164 number) 
received in the II Progress message with Progress reason set to Call progressing. 

When the ICS UE receives an II Success message, the UE shall: 

1) verify if a II session exists for the received Call-Identifier value; 

2) verify if a the message is in sequence according to the Message sequence number value; and 

3) consider the call to be established, if verification was successful. 
Editor" s note: Responses indicating an error are FFS. 

6.2.1 .2.2 ICS UE CS Session Termination without UE assisted T-ADS 

If the ICS UE receives an II Invite message from the SCC AS, and the UE determines that no II session exists for the 
received Call-Identifier value, the ICS UE shall: 

1) store the information contained in the II Invite message, including the called party identity included in the To-id 
information element, the calling user's public user identity included in the From-id information element, the lUA 
PSI DN (i.e., the E.164 number) included in the SCC-AS-id information element, the Message sequence number, 
the Call-Identifier (Part-2) subfield, the STI value (i.e. the E.164 number) if received in the Session-identifier 
information element, and transport layer information identifying the transport connection over which the II 
Invite message was received; and 

2) initiate a call over CS bearer by sending a SETUP message to the MSC Server as specified in 

3GPP TS 24.008 [3] with the Called Party BCD Number information element is set to the received SCC AS PSI 
DN (i.e., the E.164 number). 
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NOTE 1: The ICS UE may indicate the From-id information element value or an II session received indication to 
the user. 

NOTE 2: When the ICS UE receives an II Invite message, the UE may send an II Progress message with Reason 
set to Call progressing. The II Progress message with Reason set to Call progressing is identical to the II 
Progress message with Reason set to Ringing described below, except the Reason subfield wiU be set to 
Call progressing. 

Editor" s note: Responses indicating an error are FES. 

Editor's Note: It is FES whether more items are needed. The ordering of the parameters and how they are coded is 
FES. 

When the ICS UE receives an indication from the CS domain that the media resources are available (i.e. the UE 
receives a CONNECT message) the UE shall: 

1) generate an II Progress message with Progress reason set to Ringing containing the following information: 

a) a Message type subfield set to the value that indicates that is an II Progres message; 

b) a new value in the Call-Identifier (Part-1) subfield, as specified in subclause 7.2.2. The resulting Call- 
Identifier uniquely identifies this II session between the UE and SCC AS; 

NOTE 3: A new value in the Call-Identifier (Part-1) subfield is inserted only if this is the first II message sent to 
the SCC AS. Otherwise the previously set Call-Identifier value is used. 

c) increment the stored Message sequence value, store it, and include it in the Message sequence subfield; and 

d) set the Reason subfield (per figure 7.3.1) to 183; and 

2) send the II Progress message with Progress reason set to Ringing towards the SCC AS over the transport layer 
connection over which the II Invite message was received. 

If the user accepts the request, the ICS UE shall: 

1) generate an II Success message containing the following information: 

a) a Message type subfield set to the value that indicates that is an II Success message; 

b) the stored Call-Identifier value that uniquely identifies this II session between the UE and SCC AS; and 
Editor"s note: if forking is supported then such can have impact on the call-ID. 

c) increment the stored Message sequence value, store it, and include it in the Message sequence subfield; and 

Editor's Note: include a B-Party URI header value set to a SIP or tel URI is FFS. 

Editor's Note: It is FFS whether more items are needed. The ordering of the parameters and how they are coded is 
FFS. 

2) send the II Success message towards the SCC AS over the transport layer connection over which the II Invite 
message was received. 

6.2.1 .2.3 ICS UE CS Session Termination with UE assisted T-ADS 

If the ICS UE receives an II Invite message with a Replaces header field and it is determined that there is a SIP session 
being established for the Replaces header value (e.g., the Replaces header is set to a value identical to (or deduced from) 
the SIP session identifier in a previously received SIP INVITE), the ICS UE: 

1) shall interpret it as session control fallback from Gm to II; and 

2) shall use the Replaces header value to correlate the II Invite message with the SIP INVITE request prevously 
received, to get lUA PSI DN, the called party identity and the calling party identity. 

NOTE: In this case, some headers (e.g. To, From, Privacy header) and lUA PSI DN can be omitted from the II 
Invite message, for the information can be get by the ICS UE from the correlated SIP INVITE request. 
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Editor's Note: It is FFS whether more items are needed. The ordering of the parameters and how they are coded is 
FFS. 

Afterwards, the ICS UE shall behave as specified in subclause 6.2.1.2.2. 

6.2.1 .3 Detailed behaviour of SCC AS 

6.2.1 .3.1 SCC AS CS Session Origination 

The following subclause describes the procedures at the SCC AS for session origination. In this scenario, the SCC AS 
serves the originating user. 

Upon receiving an initial II Invite message from the ICS UE via the II reference point, the SCC AS shall: 

1) store the information received in the II Invite message, including the called party identity included in the To-id 
information element, the calling user's public user identity included in the From-id information element, the 
requested privacy type included in the Privacy information element, the Sequence-ID header value, and transport 
layer information identifying the transport connection over which the II Invite message was received; 

lA) dynamic Uy allocate a STI and bind it to the information stored in step 1. The STI is specified as an E.164 
number; 

NOTE 1: The STI value uniquely identifies the II session being established, and it may be subsequently used to 
refer to this II session, e.g. the SCC AS uses the STI to correlate the access transfer request received via 
the PS access with the active session established via the II interface. 

2) allocate the SCC AS PSI DN which is specified as an E. 164 number and shall identify the stored information in 
step 1) and associated with the SCC AS; 

3) generate an II Progress message containing the following information: 

a) a Message type field set to the value that indicates that is an II Progress message; 

b) include the stored Call-ID header value; 

c) add one to the stored Sequence-ID header value. Store and include the Sequence-ID header value; 

d) include the allocated SCC AS PSI DN (i.e., the E.164 number) in the SCC-AS-id information element; e) set 
the Reason field to 183 (per figure 7.3.1); and 

f) include the allocated STI (i.e., the E.164 number) in the Session-identifier information element; 

Editor's Note: It is FFS whether more items are needed. The ordering of the parameters and how they are coded is 
FFS. 

4) perform the procedures per 3GPP TS 24.292 subclause 7.4.2. 1 item 3; 

5) perform the procedures per 3GPP TS 24.292 subclause 7.4.2. 1 item 4; and 

6) send the II Progress message towards the originating UE over the transport layer connection over which the II 
Invite message was received. 

Subsequently, the SCC AS will wait for an initial SIP INVITE request from the CS domain (via MGCF) with the 
Request-URI set to the allocated SCC AS PSI DN. The SCC AS shall use the received SCC AS PSI DN and correlate it 
with the information saved in step 1). 

NOTE 2: The SCC AS will use the information received in the initial SIP INVITE request from the CS domain and 
the information saved in step 1 when sending a request toward the remote UE. 

Subsequently the SCC AS may send towards the ICS UE either an II Progress message with Progress reason set (per 
figure 7.3.1) to 180 or an II Success message. 

When sending an II Progress message with Progress reason set to 180 towards the originating UE, the SCC AS shall: 

1) generate an II Progress message containing the following information: 
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a) a Message type field set to the value that indicates that is an II Progress message; 

b) include the stored Call-ID header value; and 

c) add one to the stored Sequence-ID header value. Store and include the Sequence-ID header value; and 

2) send the II Progress message towards the originating UE over the transport layer connection over which the II 
Invite message was received. 

Editor's Note: It is FFS whether more items are needed. The ordering of the parameters and how they are coded is 
FFS. 

When sending an II Success message towards the orginating UE, the SCC AS shall: 

1) generate an II Success message containing the following information: 

a) a Message type field set to the value that indicates that is an II Success message; and 

b) a Call-Identifier field containing the Call-Identifier value that uniquely identifies this II session between the 
UE and SCC AS; 

2) add one to the stored Sequence-ID header value. Store and include the Sequence-ID header value; and 

3) send the II Success message towards the originating UE over the transport layer connection over which the II 
Invite message was received. 

Editor's Note: have the B-Party URI header value set to the value of the P-Asserted-Identity header field in the 
received SIP 200 (OK) response is FFS. 

Editor's Note: It is FFS whether more items are needed. The ordering of the parameters and how they are coded is 
FFS. 

6.2.1 .3.2 SCC AS CS Session Termination without UE assisted T-ADS 

Prior to sending an II Invite message towards the ICS UE, the SCC AS performs the Terminating Access Domain 
Selection and chooses the CS domain for the setup of the media. When sending an II Invite towards the ICS UE, the 
SCC AS shall: 

1) perform the procedures per 3GPP TS 24.292 subclause 10.4.4 item 1; 

lA)dynamiclly allocate a STL The STI is specified as an E.164 number; 

NOTE 1: The STI value uniquely identifies the II session being established, and it may be subsequently used to 

refer to this II session, e.g. the SCC AS uses the STI to correlate the access transfer request received via 
the PS access with the active session established via the II interface. 

2) create an II Invite message that includes: 

a) a Message type subfield set to the value that indicates that this is an II Invite message; 

b) generate a Call-ID that identifies the transaction between the ICS UE and SCC AS. Include the Call-ID 
header value in the II INVITE; 

Editor"s note: if forking is supported then such can have impact on the call-ID. 

c) generate a Sequence-ID. Include the Sequence-ID header value in the II Invite Message; 

d) a From-id information element that identifies the remote calling party, if available; 

NOTE 2: The SCC AS will include in the From-id information element the remote calling party only if it is an 
E.164 number. 

e) a To-id information element that includes the E. 164 number of the UE; 
Editor"s note: How to include the SIP URI into the II messages is FFS. 

f) a Privacy information element set to the value requested by the remote calling party, if available; 
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g) a SCC-AS-id information element that contains an SCC AS DN set to the E.164 number allocated by the 
sec AS itself; and 

h) a Session-identifier information element that contains the allocated STI; 

Editor's Note: It is FFS whether more items are needed. The ordering of the parameters and how they are coded is 
FFS. 

3) store the information sent in the II Invite message against the allocated SCC AS PSI DN; and 

4) select the transport layer protocol depending on the access network type, and forward the II Invite message 
toward the UE. 

When the SCC AS receives a SIP INVITE request from the CS domain with the Request URI set to a SCC AS PSI DN, 
if the SCC AS PSI DN is vahd the SCC AS shall: 

use the received SCC AS PSI DN and correlate it with the information saved in step 2 above; 

- use the SCC AS PSI DN and correlate the SCC AS PSI DN against the incoming SIP INVITE request from the 
originating UE; and 

create a response in accordance with 3GPP TS 24.229 [11], indicating local preconditions met and route towards 
CS domain. 

NOTE 3: The SCC AS will use the information received in the initial SIP INVITE request from the CS domain and 
the information saved in step 2 when handling a session with the remote party. 

NOTE 4: The receipt of the SIP INVITE request from the CS domain indicates that the UE has received the II 
Invite message. 

Subsequently the SCC AS may receive either an II Success message or an II Progress message (with Reason subfield 
set either to Ringing or Call progressing) from the ICS UE. 

When the SCC AS receives either an II Success message or an II Progress message (with Reason subfield set either to 
Ringing or Call progressing), the SCC AS shall: 

1) verify if a II session exists for the received Call-Identifier value; and 

2) verify if the message is in sequence according to the Sequence-ID header value. 

NOTE 5: The SCC AS will use the information received in the II Success message or an II Progress message (with 
Reason subfield set either to Ringing or Call progressing) and the information saved in step 2 when handling a 
session with the remote party. 

When the SCC AS receives an II Progress message prior to the related SIP INVITE request from the CS domain, the 
SCC AS shall wait until the SIP INVITE request from the CS domain is received. 

6.2.1 .3.3 SCC AS CS Session Termination with UE assisted T-ADS 

In the case of UE assisted T-ADS, the SCC AS performs initial T-ADS selecting Gm for the service control signalling 
and sends a SIP INVITE request to the ICS UE via the I/S-CSCF as specified in 3GPP TS 24.292 [5]. Upon receiving a 
183 Session Progress message from the UE which indicates that a CS bearer is required for the session and service 
control will be via II, the SCC AS shall generate an II Invite message to the terminating ICS UE as specified in 
subclause 6.2.1.3.2 with the following addition: 

1) Include a Replaces header in the II Invite message, which is set to a value identical to (or deduced from) the SIP 
session identifier in the previous SIP INVITE request, to indicate that it is session control fallback from Gm to 
II. 

NOTE: In this case, some headers (e.g.. To, From, Privacy header) and lUA PSI DN can be omitted from the II 
Invite message, for the information can be get by the ICS UE from the correlated SIP INVITE request. 

Afterwards, the SCC AS shall complete the IMS session setup as specified in subclause 6.2.1.3.2. 
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6.2.2 Session modification 

6.2.3 Session release 

6.2.3.1 General 

II sessions can be torn down by the II session release requests and by receipt of a DISCONNECT message as specified 
in 3GPP TS 24.008 [3]. An II Bye message is an II session release request. 

6.2.3.2 Detailed behaviour of ICS UE 

When the ICS UE releases a session using using the II session control channel by sending an II Bye message, it shall: 

1) set the Call-ID to a value that identifies the II session between the ICS UE and SCC AS. Include the Call-ID 
header value in the II Bye; 

2) set the Sequence-ID. Include the Sequence-ID header value in the II Bye message; 

3) a From-id information element that includes either a SIP URI or an E.164 number, and it will be used by the 
SCC AS to identify the ICS UE; 

Editor"s note: How to include the SIP URI into the II messages is FFS. 

4) a To-id information element that includes either a SIP URI or an E.164 number, and will be used by the SCC AS 
to determine the identity of the called user; 

5) a Privacy information element that indicates the ICS UE's privacy preferences. The SCC AS will apply these 
preferences to the SIP session that the SCC AS will establish on behalf of the UE; 

6) a CS access network type indicator; and 

7) if there are no more II service control sessions using the CS bearer, set the the CS bearer release timer value. 

Editor" s note: For voice calls is there a need to include any SDP type of information, by the virtue of using II in the 
context of this contribution it can be implied that CS voice is being used. 

Editor's Note: It is FFS whether more items are needed. The ordering of the parameters and how they are coded is 
FFS. The transaction style is FFS. PUD naming is FFS. 

If the CS bearer release timer expires, the ICS UE shall send a DISCONNECT message to the MSC Server as specified 
in 3GPP TS 24.008 [3], if needed. 

Subsequently, if the ICS UE receives an II Success message from the SCC AS, it shall: 

1) verify if a II session exists for the received Call-Identifier value; 

2) verify if a the message is in sequence according to the Message sequence number value; and 

3) consider the II session to be released, if verification was successful and clear the CS bearer release timer value. 
Editor" s note: Responses indicating an error are FFS. 

When the ICS UE releases a session using the II session control channel by receiving an II Bye message, it shall: 

1) if there are no more II service control sessions using the CS bearer, the UE shall send a DISCONNECT message 
to the MSC Server as specified in 3GPP TS 24.008 [3], if there are no more II service control sessions using the 
CS bearer; 

2) if there are more II service control sessions using the CS bearer, the UE shall transmit a II Success message, 
containing the following information: 

a) a Message type subfield set to the value that indicates that is an II Success message; 

b) the stored Call-Identifier value that uniquely identifies this II session between the ICS UE and SCC AS; and 
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Editor"s note: if forking is supported then such can have impact on the call-ID. 

c) increment the stored Message sequence value, store it, and include it in the Message sequence subfield. 

Editor's Note: the support for multiple II service control sessions is FFS. 

When the UE receives a DISCONNECT message to release the CS bearer as specified in 3GPP TS 24.008 [3]: 

the CS bearer release timer expires shall be cleared, if needed; 

- if the UE has a SIP REGISTER request associated with the ongoing CS call, the UE shall send a SIP relNVITE 
request requesting the media over the CS bearer to be deleted. 

If the UE receives a SIP relNVITE request requesting the media over the CS bearer to be deleted and a DISCONNECT 
message for the CS bearer was akeady received, the UE shall accept the request to delete the media over the CS bearer. 

6.2.3.3 Detailed behaviour of SCC AS 

When the SCC AS enhanced for II releases a session by sending an II Bye message, it shall implement interworking of 
established call clearing between II signalling and SIP as specified in 3GPP TS 24.292 [5], with the following addition: 

1) set the Call-ID to a value that identifies the II session between the ICS UE and SCC AS. Include the Call-ID 
header value in the II BYE; 

2) set the Sequence-ID. Include the Sequence-ID header value in the II INVITE. 

3) include a From-id information element that identifies the remote calling party, if available; 

4) include a To-id information element that includes the E. 164 number of the ICS UE; 

5) include a Privacy information element set to the value requested by the remote calling party, if available; and 

6) include a SCC-AS-id information element that contains an SCC AS DN set to the E.164 number allocated by the 
SCC AS itself; 

Editor's Note: It is FFS whether more items are needed. The ordering of the parameters and how they are coded is 
FFS. 

7) store the information sent in the II Bye message against the allocated SCC AS PSI DN. 

Subsequently, if the SCC AS receives an II Success message from the ICS UE, it shall implement interworking of 
established call clearing between II signalling and SIP as specified in 3GPP TS 24.292 [5], with the following addition: 

1) verify if a II session exists for the received Call-Identifier value; 

2) verify if a the message is in sequence according to the Message sequence number value; and 

3) consider the call to be released, if verification was successful. 

Editor" s note: Responses indicating an error are FFS. 

When the SCC AS receives an II Bye message from ICS UE via the II reference point, it shall implement interworking 
of established call clearing between II signalling and SIP as specified in 3GPP TS 24.292 [5], with the following 
addition: 

1) if the SCC AS transmits an II SUCCESS message using the II session control channel, it shall containing the 
following information: 

a) a Message type subfield set to the value that indicates that is an II Success message; 

b) the stored Call-Identifier value that uniquely identifies this II session between the ICS UE and SCC AS; and 
Editor"s note: if forking is supported then such can have impact on the call-ID. 

c) increment the stored Message sequence value, store it, and include it in the Message sequence subfield. 
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6.2.4 Adding 11 control to existing CS session (11 Augmentation) 

6.2.4.1 General 

Standard CS procedures can be used to deliver the incoming session to the ICS UE as specified in 3GPP TS 24.292 [5] 
subclause 10.4.7 (SCC AS for call termination over CS to non-ICS UE) or originate a session as specified in 
3GPP TS 24.292 [5] subclause 7.4.3 (ICS UE using CS). Additional IMS parameters or service control can be 
optionally communicated to the ICS UE using II after the session has been setup. The UE or SCC AS shall add II 
control to an existing session only when there is a single session over CS. 

6.2.4.2 Detailed behaviour of ICS UE 

If the ICS UE wants to add II control to an existing session that was established without II and Gm, it shall send an II 
Invite message over II. The ICS UE shall populate the II Invite message as specified in subclause 6.2.1.2.1 with the 
following additions: 

1) set the To information element to the static STI; 

NOTE: In this case, some information elements (e.g. From, Privacy) can be omitted from the II Invite message, 
for the information is already known for the ongoing session. 

Upon receiving an II Success message, the ICS UE shall treat the ongoing session as established using II. 

If the ICS UE receives a new II Invite message containing a SCC AS PSI DN which matches the B-party number of the 
ongoing session that was established without II and Gm, the ICS UE shall: 

1) respond to the II Invite message with an II Success message; and 

2) treat the ongoing session as established using II. 

6.2.4.3 Detailed behaviour of SCC AS 

If the SCC AS receives an II Invite message containing the static STI in the To information element, the SCC AS shall 
determine if this II Invite message is for an ongoing session using STI or CS domain number (e.g., MSISDN) from 
transport layer. If the ICS UE has an ongoing session, the SCC AS shall: 

1) respond to the II Invite message with an II Success message; and 

2) treat the ongoing session as established using II. 

If the SCC AS wants to add II control to an existing session that was established without Gm and II, the SCC AS shall 
send a new II Invite message over II reference point. The SCC AS shall populate the II Invite message as specified in 
subclause 6.2.1.2.2 with the following addition: 

1) include a SCC AS PSI DN which matches the B-party number of the ongoing session. 

NOTE: In this case, some information elements (e.g. From, To, Privacy ) can be omitted from the II Invite 
message, for the information is already known for the ongoing session. 

Upon receiving an II Success message, the SCC AS shall treat the ongoing session as established using II. 

6.2.5 Service control transfer (Gm fallback to II ) 

6.2.5.1 General 

If the ICS UE discovers Gm is not available for an ongoing session using CS bearer which was established over Gm 
reference point, the ICS UE can transfer service control from Gm to II if II is available while maintain the CS bearer. 

6.2.5.2 Detailed behaviour of ICS UE 

When the ICS UE originates a service control transfer from Gm to II using an Illnvite message, the ICS UE shall 
generate the II Invite message to the SCC AS as specified in subclause 6.2.1.2.1 with the following additions: 



£75/ 



3GPP TS 24.294 version 9.0.0 Release 9 



19 



ETSI TS 124 294 V9.0.0 (2010-01) 



1) Include a Replaces information element in the II Invite message to indicate that it is session control fallback 
from Gm to II. The Replaces information element is set to a value identical to (or deduced from) the SIP session 
identifier of the existing IMS session using CS bearer for which the control will be transferred from Gm to II. 

NOTE: In this case, some information elements (e.g. Call-ID, To, From, Privacy) can be omitted from the II 
Invite message, for the information is already known for the ongoing session. 

If the ICS UE receives an II Success message, the service control transfer completes. 



6.2.5.3 



Detailed behaviour of SCC AS 



Upon receiving an initial II Invite message with a Replaces information element set to a value identical to (or deduced 
from) the SIP session identifier of an existing IMS session using CS bearer established over Gm reference point, and the 
SCC AS can correlate the SIP Call-ID to an existing IMS session with CS bearer, the SCC AS shall: 

1) interpret it as service control transfer from Gm to II; 

2) correlate the II Invite message to the existing IMS session using CS bearer based on the Replaces information 
element, e.g. to get SCC AS PSI DN, the called party identity and the calling party identity; and 

NOTE: In this case, some information elements (e.g. Call-ID, To, From, Privacy) can be omitted from the II 
Invite message, for the information is already known for the ongoing session. 

3) generate an II Success message to the ICS UE. 

6.3 Supplementary services control procedures 

Editor's note: This subclause describes the procedures related to supplementary services control procedures 
supported by II interface. 



7 



Protocol specification and implementation 



7.1 Overview of 11 protocol functionality 

The II protocol includes the procedures for establishing, maintaining, and clearing call legs between the ICS UE and 
the SCC AS (see figure 7.1). 






II 



CS Access 



MSC Server 



SCC AS 
ISC 
CSCF 

SIP signalling 



MGCF 



MGW 



Figure 7.1 UE session signalling and bearer path using II interface for Service Control Signalling 

Path 

NOTE 1: Figure 7.1 illustrates an MSC server that is not enhanced for ICS. II can also be used when deploying an 
MSC server enhanced for ICS as specified in 3GPP TS 23.292 [2]. 

The II protocol is a message based point-to-point protocol. The II protocol messages are wrapped in a point-to-point 
transport layer connection protocol (e.g.USSD) and are exchanged between the ICS UE and the SCC AS. Therefore, the 
II protocol does not include any routing capabilities. To address the ICS UE in CS network and establish a transport- 
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layer connection, (the lUA of) the SCC AS shall convert the called party identity (i.e., IMS public user identity) to the 
CS domain party identity that is required to route the transport layer protocol(i.e., MSISDN, MDN, etc.). 

The II protocol assumes that there is an associated connection-control protocol that incorporates media negotiation 
capabilities and provides the setting up and clearing of the connection over which the media will be exchanged. 
Therefore, any signalling between the UE and the CS access domain (see figure 7.1), as well as the SIP signalling 
between the MGCF and the SCC AS should be viewed as a procedure to establish a media connection rather then a call 
control signalling. Obviously, the II endpoints will correlate and synchronize the progress of the call establishment and 
clearing of the call with the associated media-establishing procedures. 

NOTE 2: The primitives that are used to communicate between the II protocol call-controlling entity and the 
associated connection-control protocol entity, internally in the UE and SCC AS, respectively, are not 
specified in this document. 

The II protocol assumes that the application level segmentation of the II protocol messages is not supported. The size 
of the II protocol messages is constrained by the limits of the transport-layer message size. For example, USSD allows 
for a message size of 160 octets. This means that it is not possible to send an II protocol message greater than 160 
octets, unless message segmentation is designed into the II protocol. A USSD dialogue is already segmented by the use 
of USSD sub-dialogues as a USSD conversation, and this usage of USSD is inappropriate for the II protocol. 

Editor's note: It has to be specified whether the transport-layer connection provides a reliable transport (i.e. the 
messages will not be lost, delayed, duplicated, or delivered out of order). In case of an unreliable 
transport, the II protocol will incorporate timeouts, retransmissions, and sequencing mechanisms to 
account for the lost, duplicated, and out of order II protocol messages. 

The II protocol is a transport-independent protocol, i.e. the II protocol call control entities can exchange the II protocol 
messages over any transport-layer connection that connects the ICS UE and the SCC AS. The ICS UE sends the II 
protocol messages to the SCC AS over a transport-layer connection (e.g. USSD) that the ICS UE knows it will reach the 
SCC AS. Likewise, The SCC AS sends the II protocol messages to the ICS UE over a transport-layer connection (e.g. 
USSD) that the SCC AS knows that it will reach the ICS UE. For example, the SCC AS forwards the II protocol 
message to the ICS UE over the same transport-layer connection (e.g. USSD) over which it received the previous II 
protocol message from the ICS UE. 

The II protocol message are self-identifying, i.e. the information contained in the II protocol message uniquely 
identifies the call to which the II protocol message pertains to. 

Editor's Note: It is FFS how a particular UE's public user identity bound to a given transport-level connection used 
for signaling, will be described. For example, the establishment of an USSD channel can implicitly bind 
the UE's E.164 number to this transport-layer connection. 

The II protocol is a binary-oriented protocol (i.e. the II messages are binary encoded). The bit-map tables are used to 
describe the II messages and associated information elements. 

In this release of this document, it is assumed that the ICS UE, when establishing a transport-layer connection (e.g. 
USSD channel) to the SCC AS, will have been authenticated by the CS domain. Due to a relationship between the SCC 
AS and the CS domain, the ICS UE is not authenticated (e.g. challenged) by the SCC AS when sending any II protocol 
message to the SCC AS. However, the SCC AS will check the UE identity for potential invalid IMS public user identity 
included by the ICS UE. The CS domain number received from the transport-layer is trustable and will be used by (the 
lUA of) the SCC AS to check the URI of the UE before the SCC AS provides SIP UA behaviour on behalf of the ICS 
UE. 

7.2 11 -protocol messages and functional definition 
7.2.1 II -protocol messages 
7.2.1.1 General 

This subclause provides the list of Il-protocol messages (see table 7.2.1) and brief description of each Il-protocol 
message. Based on their function the Il-protocol messages can be grouped into five categories: 

Il-Session establishment messages; 
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- Il-Stable Session messages; 
Il-Session clearing messages; 

- II -Error messages; 

II- Supplementary Service -Invocation messages;and 
Il-Other messages. 
Editor's Note: the need for an Il-other messages such as II Dummy message is FFS. 
Editor's note: a definition of the term stable call is FFS 

Table 7.2.1.1: 11-protocol messages 



Message type 


Description and 

content 

(subclause) 


Session establishment messages: 


7.2.1.2 


11 Invite message 
11 Progress message 
11 Success message 








Stable Session messages: 


7.2.1.3 


11 Refer message 




Session clearing messages: 


7.2.1.4 


11 Bye message 
11 Success message 




Error messages: 


7.2.1.5 


11 Failure message 




Supplementary Service Invocation messages: 


7.2.1.6 


11 Mid Call Request message 
11 Redirection message 
11 Notify message 




Other messages: 




11 Dummy message 


7.2.1.7 



Editor's note: it is FFS if an II Cancel message would be needed in addition to the II Bye message. 
Editor's Note: the need for a II Dummy message is FFS 

7.2.1 .2 Session establishment messages 

The session establishment II messages can be sent either by the ICS UE to the SCC AS or by the SCC AS to the ICS 
UE. 

II Invite message 

The II Invite message is sent either by the calling UE to the SCC AS or by the SCC AS to the called UE to initiate 
session establishment. 

II Progress message 

The II Progress message is a general purpose provisional response, semantically similar to SIP Ixx class responses. The 
binary Reason field value (per figure 7.3.1) corresponds with the received SIP Ixx response's numeric status-code 
value. 
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Editor"s note: depending on whether the transport-layer connection provides a reliable transport, the II Progress 
message with Progress reason set to Call progressing can quench the retransmissions of the II Invite 
messages. In case of forking, it is FFS if the SCC AS, upon receiving an Il-Invite message from the UE, 
responds with multiple II Progress messages with Progress reason set to Call progressing due to a 
forking. Each II Progress message with Progress reason set to Call progressing may result in a distinct 
call leg between the UE and the SCC AS, with a distinct call identifier for each call leg. 

II Success message 

The II Success message indicates that the action requested in the respective II message has been accomplished 
successfully. 

The II Success message: 

is transmitted by the SCC AS to the calling UE to indicate that the session has been accepted; or 

is transmitted by the called UE to the SCC AS to indicate that the called UE has accepted the session. 

The Reason's corresponding to the II Success message are specified in table 7.3.1 and correspond with a SIP 2xx 
response's numeric status-code. 

Editor"s note: In case of forking, it is FFS if the SCC AS, upon receiving an Il-Setup request message from the UE 
may respond back to the UE with multiple II -Setup-Complete final-response messages due to a forking of 
the original Il-Setup request message. Each II -Setup-Complete final-response message returned to the 
UE may result in a distinct call leg with a distinct call identifier for each call leg. 

7.2.1 .3 Stable session messages 

II Refer message 

The II Refer message is sent either by the ICS UE to the SCC AS or by the SCC AS to the ICS UE to indicate that the 
recipient of the II Refer message should contact the target identified in the II Refer message. 

Editor" s Note: Whether the II Refer request sent outside an existing call creates a call, and how is the sender of the 
II Refer request notified about the outcome of the referenced request is FFS. In addition, it may be useful 
to have some flows in order to determine e.g. whether this message is a stable call as well as a non call 
category message 

7.2.1.4 Session clearing messages 

II Bye message 

The II Bye message: 

is transmitted by the SCC AS to the ICS UE to clear the session; or 

is transmitted by the ICS UE to the SCC AS to clear the session. 

Editor"s Note: Whether an indication needs to be transmitted that the call has disconnected in response to an II Bye 
message and that the media and associated resources (if any) have been released, is FFS. 

7.2.1.5 Error messages 

II Failure message 

An II Failure response message is sent either by the ICS UE to the SCC AS or by the SCC AS to the ICS UE, to 
indicate that an error has occurred. The additional parameters included in the Il-Error message indicate the type of the 
error that has occurred. These are similar to SIP 4xx class failure messages. 

7.2.1 .6 Supplementary Services Invocation related messages 

The following section details the messages that are used to request the invocation of a supplementary service. 
II Mid Call Request message 
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The II Mid Call Message is used for the invocation of mid-call supplementary services. For example: user wishes to 
hold or resume a call. 

II Redirection message 

The II Redirection message is used by the ICS UE to inform the SCC AS of the desire to invoke a supplementary 
service, in response to incoming signalling. For example: desire for the called user to deflect the call to a third party. 
The SCC AS interworks the II response to the appropriate SIP response to send to the SIP AS. 

II Notify message 

The II Notify message may be used to notify the UE of events related to the invocation of supplementary services. For 
example: 

Notification that a call has been forwarded to a third party; 

Notifications related to Explicit Call Transfer; or 

Notifications related to requests to join a Conference. 

7.2.1 .7 Other messages 

II Dummy message 

The II Dummy message is only used for those specific transport-layer connections (e.g., USSD) which provide two- 
way-alternative interactive service. If the party which has the turn hasn't sent an application level protocol message for a 
specific time, an II Dummy message shall be delivered to the counterpart to transfer the turn with the consideration of 
not delaying its transmission of application protocol message. 

Editor's Note: the need for an II Dummy message is FFS. 

7.2.2 11 message structure and common field encoding 
7.2.2.1 General 



7.2.2.1.1 



Message Header structure 



The II message structure is shown in figure 7.2.2.1. Each II messages consists of two parts, i.e. the first part referred to 
as the II message common part and the second part consisting of zero or more II information elements. The II message 
common part is included in every II message. The II information elements that are included in an II message depend 
on a type of II message being sent. 

The text in this clause describes the content of the II message common part. The octet number 1 (shown at the top of 
the figure 7.2.2.1) is sent first followed by octet 2, 3, etc. Within each octet, the bit designated "bit 1" is transmitted 
first, followed by bits 2, 3, 4, etc. 



8 7 6 5 


4 3 2 1 


Octet 


Protocol version number 


Protocol identifier 


1 


Message type R Reason 


2 


Reason 


3 


Call-Identifier (Part-1) 


4 


Call-Identifier (Part-2) 


5 


Call-Identifier (Part-2) 


6 


Sequence-ID 


7 


Information element #1 




Information element #2 



Figure 7.2.2.1 : II message structure 
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7.2.2.1 .2 Protocol Version information 

The first octet is divided into two four-bit subfields, i.e. the Protocol identifier and the Protocol version number. The 
Protocol identifier for II protocol is "0001" and indicates that the respective message, transported across the transport- 
layer connection, is an II protocol message. The Protocol version number indicates that this is the first version of this 
specification and the respective value of the Protocol version number subfield is "0001". 

7.2.2.1 .3 Message Type and Reason 

The second octet and third consists of five-bit Message type field that identifies the type of the II message, while the 
ten-bit Reason fields provide additional information about the respective II message, i.e.. Progress reason value, as 
specified in table 7.2.2.1. If the three-bit Message type parameter is set to "00000", it indicates that the Reason field is 
used. If the five-bit Message type parameter is not set to "00000", it indicates that the Reason field is not used and it 
shall be ignored. 

7.2.2.1.4 Callldentifier 

The three octets (i.e. the octet number 4, 5, and 6) that follow the Reason type field contain the Call-Identifier field. The 
Call-Identifier field uniquely specify the call across all II interfaces (i.e. between the ICS AS and all ICS UEs 
connected to the ICS AS). The Call-Identifier field is divided into two subfields, i.e. the part-1 subfield consisting of 
one octet and the part-2 subfield consisting of two octets. The part 1 subfield is always filled by the UE, while the part-2 
subfield is always filled by the ICS AS. The part-1 and part-2 subfields are analogous to the SIP tags inserted in the 
From and To header fields. The values of all "0" inserted in the octet 3 (i.e. in the Call-Identifier Part-1) indicates that 
the Call-Identifier (Part-1) subfield is empty (i.e. it has no value). Likewise, values of all "0" inserted in the octet 4 
and 5 (i.e., in the Call-Identifier Part-2) indicates that the Call-Identifier Part-2 subfield is empty (i.e., it has no value). 
When the UE forwards the first II message pertaining to a call that is being established (e.g., an II Invite or an II 
Progress) to the ICS AS, the UE inserts a new value into the Call-Identifier (Part-1) subfield (i.e., a value that is 
currently not being unused). Likewise, when the ICS AS forwards the first II message pertaining to a call that is being 
established (e.g., an II Invite or an II Progress) to the UE, the ICS AS inserts a value into the part-2 subfield. When 
inserting a value into the Call-Identifier (Part-2) subfield, the ICS AS has to insure that the resulting Call-Identifier field 
is unique across all II interfaces. For example, the ICS AS, upon receiving the first II message from the ICS UE, may 
insert into the Call-Identifier (Part-2) subfield a value that it is currently using in some other calls, only if the resulting 
Call-Identifier field is unique across all II interfaces (i.e. between the ICS AS and all ICS UEs). 

Editor's Note: It is FES whether the Call-Identifier (Part-2) subfield needs two octets. 

7.2.2.1.5 Sequence-ID 

The Sequence-ID field value (i.e., the octet number 7) guarantees the proper ordering of the II message. The sender of 
the II message increments the Message sequence number value by one for each new II message forwarded to its peer. 
The sequence number value is expressible as an 8-bit unsigned integer. Once the count reaches the value of 2**8, it 
wraps around back to one. 

Editor's Note: It is FFS how long the Sequence-ID should be (i.e whether to use a single octet or if two octets are 
needed). 



7.3 Messages 

7.3.1 General Messages 

Table 7.3.1 summarizes the messages for II. 
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Table 7.3.1 : General Message types 



Message 


Message Type Value (5 bit) 
hex 


Reason Value (10 bit) hex 


11 INVITE 


0x1 


0x000 


11 BYE 


0x2 


0x000 


11 REFER 


0x9 


0x000 


11 PROGRESS 


0x00 


0x64 - 0xC7 


11 SUCCESS 


0x00 


0xC8-0x12B 


11 FAILURE 


0x00 


0x1 90- 0x1 F3 


11 Dummy 


0x00 


0x3FF 



Editor's Note: the need for the II Dummy message is FFS. 

7.3.2 11 INVITE - ICS UE initiated 
7.3.2.1 General 

This message is sent by the ICE UE to the network to establishment of a session. See table 7.3.2.1. 
Message type: II INVITE 
Direction: ICS UE to SCC AS 

Table 7.3.2.1 : II INVITE message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Protocol Information 


Protocol Information 


M 


V 


1 




7.2.2.1.2 








Message Type 


Request Message - INVITE 
7.2.2.2.1.2 


M 


V 


2 


Call ID 


Call-Id 
7.2.2.1.4 


M 


V 


2 


Message Sequence Number 


Sequence-Id 
7.2.2.1.5 


M 


V 


1 


To 


To 
7.3.2.3 


M 


LV 


FFS 


From 


From 
7.3.2.4 





LV 


FFS 



7.3.2.2 



Message Type 



Identifies that the message is: 
i) an II INVITE. 



7.3.2.3 



To 



This information element shall be included, it identifies the logical identity of the recipient for the request according to 
the procedures specified in RFC 3261 [6]. 

Editors Note: It is FFS how the To element is to be encoded. 



7.3.2.4 



From 



This information element shall be optionally included, it identifies the logical identity that the dialogue originates from 
according to the procedures specified in RFC 3261 [6]. 

Editors Note: It is FFS how the From element is to be encoded. 
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7.3.3 INVITE - sec AS initiated 
7.3.3.1 General 

This message is sent by the SCC AS to the ICS UE to establishment of a session. See table 7.3.3. 1 . 
Message type: II INVITE. 
Direction: SCC AS to ICS UE 

Table 7.3.3.1 : II INVITE message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Protocol Information 


Protocol Information 
7.2.2.1.2 


M 


V 


1 


Message Type 


Request Message - INVITE 
7.2.2.2.2.2 


M 


V 


2 


CalllD 


Call-Id 
7.2.2.1.4 


M 


V 


2 


Message Sequence Number 


Sequence- Id 
7.2.2.1.5 


M 


V 


1 


From 


From 
7.3.3.3 


M 


LV 


FFS 


SCC AS PSI DN 


SCC AS PSI DN 


M 


LV 


3-15 


To 


To 
7.3.3.4 


M 


LV 


FFS 



7.3.3.2 



Message Type 



Identifies that the message is: 
i) an II INVITE. 



7.3.3.3 



From 



This information element shall be included; it identifies the logical identity that the dialogue originates from. It is the 
same as that defined in RFC 3261 [6] however no display name is included. 

Editor's Note: It is FFS how the From element is to be encoded. 



7.3.3.4 



To 



This information element shall be optionally included; it identifies the logical identity of the recipient for the request. 
It is the same as that defined in RFC 3261 [6]. 

Editor's Note: It is FFS how the To element is to be encoded. 

7.3.3.5 SCC AS PSI DN 

This information element shall be included; it uniquely identifies the SCC AS and session on that AS. 

7.3.4 BYE - ICS UE initiated 
7.3.4.1 General 

This message is sent by the ICS UE to the SCC AS to establishment of a session. See table 7.3.4.1. 
Message type: II BYE 
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Direction: ICS UE to SCC AS 

Table 7.3.4.1 : II BYE message content 



Information 
element 


Type/Reference 


Presence 


Format 


Length 


Protocol Information 


Protocol Information 
7.2.2.1.2 


M 


V 


1 


Message Type 


Request Message - BYE 
7.3.4.2 


M 


V 


2 


CalllD 


Call-Id 
7.2.2.1.4 


M 


V 


2 



7.3.4.2 



Message Type 



Identifies that the message is: 
i) an II BYE. 

7.3.5 BYE - SCC AS initiated 
7.3.5.1 General 

This message is sent by the SCC AS to the ICS UE to establish of a session. See table 7.3.5.1. 
Message type: II BYE 
Direction: SCC AS to ICS UE 

Table 7.3.5.1 : II BYE message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Protocol Information 


Protocol Information 
7.2.2.1.2 


M 


V 


1 


Message Type 


Request Message - BYE 
7.3.5.2 


M 


V 


2 


CalllD 


Call-Id 
7.2.2.1.4 


M 


V 


2 



7.3.5.2 



Message Type 



Identifies that the message is: 
i) an II BYE. 

7.3.6 11 PROGRESS - ICS UE initiated 
7.3.6.1 General 

This message is sent by the ICE UE to the network to establish of a session. See table 7.3.6. 1. 
Message type: II PROGRESS 
Direction: ICS UE to SCC AS 
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Table 7.3.6.1 : II PROGRESS message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Protocol Information 


Protocol Information 


M 


V 


1 




7.2.2.1.2 








Message Type 


Request Message - PROGRESS 
7.3.6.2 


M 


V 


2 


CalllD 


Call-Id 
7.2.2.1.4 


M 


V 


2 


Message Sequence Number 


Sequence-Id 
7.2.2.1.5 


M 


V 


1 



7.3.6.2 



Message Type 



Identifies that the message is 
i) an II PROGRESS. 

7.3.7 11 PROGRESS - SCC AS initiated 
7.3.7.1 General 

This message is sent by the SCC AS to the ICS UE to establish of a session. See table 7.3.3.1. 
Message type: II PROGRESS 
Direction: SCC AS to ICS UE 

Table 7.3.3.1 : II PROGRESS message content 



Information element 


Type/Reference 


Presence 


Format 


Length 


Protocol Information 


Protocol Information 


M 


V 


1 




7.2.2.1.2 








Message Type 


Request Message - PROGRESS 
7.3.7.2 


M 


V 


2 


CalllD 


Call-Id 
7.2.2.1.4 


M 


V 


2 


Message Sequence Number 


Sequence-Id 
7.2.2.1.5 


M 


V 


1 


SCC AS PSI DN 


SCC AS PSI DN 
TBD 


M 


LV 


?? 



7.3.7.2 



Message Type 



Identifies that the message is: 
i) an II PROGRESS. 



7.4 



II Information elements and functional definition 



7.4.1 II information elements 

The list of the II information elements is shown in table 7.4.1. 

Editor"s Note: The list of II information elements is not complete. 
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Table 7.4.1 II -information elements 



11 information element 
Name 


Description and 

content 

(subclauses) 


Error-code 


7.4.2.2 


From-id 


7.4.2.3 


Privacy 


7.4.2.4 


SCC-AS-id 


7.4.2.5 


Session-identifier 


7.4.2.6 


To-id 


7.4.2.7 


Replaces 


7.4.2.8 



Error-code 

The Error-code information element is included in every Il-Error response message. The Error-code information 
element is binary encoded SIP failure response. The SIP 4xx request failure responses, the 5xx server failure responses, 
and the 6xx global failure responses are binary encoded and included in the Error-code information element as specified 
in subclause 7.4.2.1 and table 7.4.2.1. The interpretation of each binary encoded failure response is analogous to the 
interpretation of associated SIP failure response. 

From-id 

The From-id information element specifies the identity of the calling user, e.g., the calling party number. The From-id 
information element may contain either an E.164 or a SIP URI. 

Editor's Note: The II protocol assumes that the II protocol messages will not be segmented. Hence, the size of the 
II protocol messages is constrained by the limits of the transport-layer message size, e.g. the USSD 
allows for a message size of 160 bytes. Therefore, it is FFS how to fit the SIP URIs into the limited-size 
II messages. 

Privacy 

The UE uses the Privacy information element to indicate to the SCC AS how to handle the SIP header fields when the 
sec AS forwards the SIP requests and responses on behalf of the UE to the far-end UA. The Privacy information 
element when sent by the UE to the SCC AS contains binary encoded "priv-value" (as specified in the RFC 3323 and 
RFC 3325). When the SCC AS, upon receiving a Privacy information element over II interface, forwards a SIP request 
or a response to the far-end UA, the SCC AS behaves as specified in the RFC 3323 and RFC 3325 e.g. the SCC AS 
inserts a P-Asserted-Identity header field into SIP message as requested by the Privacy information element. 

SCC-AS-id 

The SCC-AS-id information element contains an URI that points to the SCC AS. When the UE sets up a CS bearer 
connection by sending a SETUP message to the MSC server, the UE specifies the respective URI as the called party 
number. Subsequently the call will be routed to the respective SCC AS via a MGCF. 

Session-identifier 

The Session-identifier information element is an identifier used either by the UE or the SCC AS to uniquely and 
globally identify a session across all interface (i.e. the II interface, Gm interface and the IMS). The Session identifier is 
dynamically allocated by the SCC AS to identify the II session that is being established. The SCC AS includes the 
Session-identifier information element in the first II message sent by the SCC AS to the UE. The Session-identifier 
information element may contain different values, e.g. the Session Transfer Identifier (STI), as specified in 
subclause 7.4.2.1 and associated subclause 7.4.2.1. 

To-id 

The To-id information element specifies the identity of the called user, e.g., the called party number. The To-id 
information element may contain an URI. 

Editor's Note: The II protocol assumes that the II protocol messages will not be segmented. Hence, the size of the 
II protocol messages is constrained by the limits of the transport-layer message size, e.g. the USSD 
allows for a message size of 160 bytes. Therefore, it is FFS how to fit the SIP URIs into the limited-size 
II messages. 
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Replaces 

The Replaces information element is used by the UE to identify an existing call or a SIP dialog that will be replaced 
with a call being established over the II interface. When the UE wants to replace an existing call or a SIP dialog with a 
new call, the UE sends an II Invite request message to the SCC AS with the Replaces information element that contains 
the identity of the SIP dialog or a call that will be replaced with a new call being established. In the case of UE assisted 
T-ADS, the SCC AS may send an II Invite request message to the terminating ICS UE with Replaces information 
element that contains the identity of the SIP dialog to change the service control for the session from Gm to II. 

7.4.2 11 Information elements encoding 
7.4.2.1 General 

The structure of the II information elements is shown in figure 7.4.2.1. 



8 7 6 5 4 


3 2 1 


Octet 


Information Element code 


Code specific 


1 


Information Element length (in octets) 


2 


Information Element body (as required) 


3 


etc. 









Figure 7.4.2.1 : II information element format 

Each II information element contains a common two-octet field followed by a variable-size body. The first octet 
contains the Information Element code and Code specific values. Each II information element is uniquely identified 
with the respective Information Element code (i.e., encoded with bits numbered 4, 5, to 8 of the first octet). The Code 
specific value (i.e., encoded with bits numbered 1, 2, and 3 of the first octet) provide additional information about 
respective II information element. For example, if the Information Element code specifies that this is a To-id II 
information element, then the Code specific value will indicate whether the Information Element body contains an 
E.164 number or SIP URI. The Code specific values for each respective II information element are described in the 
respective subclauses. 

The second octet i.e. the Information Element length specifies the length of the II information element body (i.e., the 
number of octets following the Information Element length) in binary format. The bit number 1 of octet number 2 is the 
list significant bit and bit number 8 of the octet number 2 is the most significant bit. The table 7.4.2.1 specifies the 
Information Element code for each II information element. 



Table 7.4.2.1 : II -information element coding 



Information 
Element code 


11 information element 
Name 


Reference 
subclause 


Bits 
87654 






10001 


Error-code 


7.4.2.2 


10011 


From-id 


7.4.2.3 


10100 


Privacy 


7.4.2.4 


10 101 


SCC-AS-id 


7.4.2.5 


10110 


Session-identifier 


7.43.2.6 


10111 


To-id 


7.4.2.7 


10010 


Replaces 


7.4.2.8 



Editor" s Note: Some II Information elements may be of a fixed size. Hence, it is FFS whether the Information 
Element length is needed for each Information element. 



7.4.2.2 



Error-code 



Editor" s Note: How and which additional waning-codes and reason-values are encoded and included in the Error- 
code information element is FFS. 
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7.4.2.3 



From-id 



The purpose of the From-id information element is to identify the originator of the call. The From-id information 
element may contain either a SIP URI or a telephone number (e.g. international number, national number). The Code 
specific field, i.e., the bits 3, 2, and 1 of the octet number 1 specify the type of information contained in the From-id 
information element, and is used to identify the target of the call. 

When the Code specific field, i.e., the bits 3, 2, and 1 of the octet number 1 is set to "001" it indicates that the From-id 
information element contains an E.164 (see table 7.4.2.1.1). When the From-id information element contains an 
international number (i.e. an E.164 number), the E.164 digit-string is included in the octet 3, octet 4, octet 5, etc. as 
follows: 

the bits numbers 8, 7, 6, and 5 of octet number 3 are used to binary encode the most significant digit of the 
E.164 digit-string; 

the bits numbers 4, 3, 2, and 1 of octet number 3 are used binary encode the next significant digit of the E. 164 
digit-string; 

the bits numbers 8, 7, 6, and 5 of octet number 4 are used binary encode the next significant digit of the E. 164 
digit-string; and so on until the entire E.164 digit-string is included in the From-id information element; and 

the bit-pattern "1111 "iserted either in the bits 8, 7, 6, and 5 or bits 4, 3, 2, and 1 of any octet indicates the end of 
the E. 164 digit-string, i.e. the bit-pattern of " 1 1 1 1" is used as the end-delimiter for the E. 164 digit-string. 



8 


7 6 5 4 


3 2 1 


Octet 


1 
1 


Information Element code 

1 


Code specific 


1 


Information Element length (in octets) 


2 


Information Element body 


3 


etc. 



Figure 7.4.2.3.1 : From-id information element 



Table 7.4.2.3.1 : From-id information element 



(octet 1) 


Code specific 






Bits 


321 




000 


Unspecified 


001 


International number, i.e. E.164 number (Note 1) 


010 


SIP URI 


01 1 


SIP URI where the user part of the SIP URI contains a telephone number, i.e. 
with user=phone 


SIP URI 




Other values are reserved for future use 


(octet 3) 


Bits 


8765 


the most significant digit of the E.164 digit-string 


(octet 3) 


Bits 


4321 


the next significant digit of the E.164 digit-string 


(Note 2) 




(octet 4) 


Bits 


8765 


the next significant digit of the E.164 digit-string 


(Note 2) 




(octet 4) 


Bits 


4321 


the next significant digit of the E.164 digit-string 


(Note 2) 
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(next octet) 



Bits 

(Note 2) 



(Note 3) 



Note 1 - Prefix or escape digits shall not be included. 

Note 2 - the next significant digits of the E. 164 digit-string are included in subsequent bits 8, 7, 6, and 5 or 
bits 4, 3, 2. 

Note 3 - The E. 164 digit-string terminates with delimiter "1111" in the bits 8, 7, 6, and 5 or bits 4, 3, 2, 
and 1 of any octet indicating the end of the E. 164 digit-string. 



7.4.2.4 



Privacy 



The ICS UE may include the Privacy information element in the II Invite message to indicate its privacy preferences 
that the SCC AS should apply to the SIP session toward the remote UE. When the SCC AS sets up a SIP session on 
behalf of the UE, the SCC AS sends a SIP INVITE request that includes the privacy information that the SCC AS 
received in the Privacy information element. 

The Privacy information element when sent by the ICS UE to the SCC AS contains binary encoded "priv-value" (as 
specified in the RFC 3323 and RFC 3325). Note that the UE may request multiple types of privacy for the same call 
(see RFC 3323). Hence, the UE include all of the requested privacy types in its Privacy information element by setting 
the respective bits as shown in table 7.4.2.4.1. 



8 


7 1 6 1 5 1 4 


3 2 


1 


Octet 


Information Element code 
1 1 



Code specific 








1 


Information Element length (in octets) 


2 


Information Element body 


3 











Figure 7.4.2.4.1 : Privacy information element 



7.4.2.5 



SCC-AS-id 



The SCC-AS-id information element contains an URI that points to the SCC AS. The SCC-AS-id information element 
may contain either a SIP URI or an international telephone number (i.e. an E. 164 national number). The Code specific 
field, i.e., the bits 3, 2, and 1 of the octet number 1 in figure 7.4.2.5.1 specify the type of information that is used to 
identify the SCC AS. When the SCC AS forwards a PSI DN associated with the SCC AS to the UE, the SCC AS will 
include the PSI DN in the SCC-AS-id information element. The PSI DN is an E.164 number. 

Editor"s Note: How to include non-international numbering plans, SIP URI, and SIP URI with user=phone into the 
From-id information element is FFS. 

When the Code specific field, i.e., the bits 3, 2, and 1 of the octet number 1 is set to "001" it indicates that the SCC-AS- 
id information element contains a PSI DN (i.e. an E.164 number). When the SCC-AS-id information element contains a 
PSI DN (i.e. an E.164 number), the E.164 digit-string is included in the octet 3, octet 4, octet 5, etc. as shown in 
table 7.4.2.5.1. 
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Figure 7.4.2.5.1 : SCC-AS-id information element 
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Table 7.4.2.5.1 : SCC-AS-id information element 



(octet 1) 


Code specific 


Bits 




321 




000 


Unspecified 


001 


PSI DN, i.e. E.164 number (Note 1) 




Other values are reserved for future use 


(octet 3) 




Bits 




8765 


the most significant digit of the E. 164 digit-string 


(octet 3) 




Bits 




4321 


the next significant digit of the E. 164 digit-string (Note 2) 


(octet 4) 




Bits 




8765 


the next significant digit of the E. 164 digit-string (Note 2) 


(octet 4) 




Bits 




4321 


the next significant digit of the E. 164 digit-string (Note 2) 


(next octet) 




Bits 






(Note 3) 


Note 1 - Prefix 


or escape digits shall not be included. 


Note 2 - the next significant digits of the E. 164 digit-string are included in subsequent bits 8, 7, 6, and 5 or 


bits 4, 3, 2. 




Note 3 - The E. 164 digit-string terminates with delimiter " 1 1 11" in the bits 8, 7, 6, and 5 or bits 4, 3, 2, 


and 1 of any octet indicating the end of the E. 164 digit-string. 



7.4.2.6 Session-identifier 

The Session-identifier information element is used either by the ICS UE or the SCC AS to covey the identity of the 
session being established. The Code specific subfield, i.e., the bits 3, 2, and 1 of the octet number 1 specify the type of 
information that is used to identify the session across. 

When a SIP dialog or an 11 session is identified with an E.164 number (e.g. with a STl), then this identifier is conveyed 
across the II interface in a Session-identifier information element. In this case, the Code specific field, i.e., the bits 3, 2, 
and 1 of the octet number 1 is set to "001", as shown in figure 7.4.2.6.1 and table 7.4.2.6.1 

Editor's Note: It has to be clarified whether the term STI is appropriate in all cases, or whether the term STN should 
be used in some cases. 

Editor's Note: How to include a SIP dialog identifier (i.e. the From tag, the To tag, and the Call-ID into the Session- 
identifier information element is FFS. 
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Figure 7.4.2.6.1 : SCC-AS-id information element 
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Table 7.4.2.6.1 : SCC-AS-id information element 



(octet 1) 
Bits 
321 
000 
001 



Code specific 



Unspecified 

Session or a dialog identified with an E.164 number (Note 1) 

Other values are reserved for future use 



(octet 3) 
Bits 
8765 



the most significant digit of the E. 164 digit-string 



(octet 3) 

Bits 

4 3 2 1 the next significant digit of the E. 164 digit-string (Note 2) 



(octet 4) 
Bits 
8 7 6 5 the next significant digit of the E. 164 digit-string (Note 2) 



(octet 4) 

Bits 

4 3 2 1 the next significant digit of the E.164 digit-string (Note 2) 

(next octet) 

Bits 

(Note 3) 
Note 1 - Prefix or escape digits shall not be included. 

Note 2 - the next significant digits of the E. 164 digit-string are included in subsequent bits 8, 7, 6, and 5 or 
bits 4, 3, 2. 

Note 3 - The E. 164 digit-string terminates with delimiter "1111" in the bits 8, 7, 6, and 5 or bits 4, 3, 2, 
and 1 of any octet indicating the end of the E. 164 digit-string. 



7.4.2.7 



To-id 



The purpose of the To-id information element is to identify the called party of a call. The To-id information element 
may contain either a SIP URI or a telephone number (e.g. international number, national number). The Code specific 
field, i.e., the bits 3, 2, and 1 of the octet number 1 specify the type of information contained in the To-id information 
element, and is used to identify the target of the call. The To-id information element is shown in figure 7.4.2.7.1. 

Editor" s Note: How to include non-international numbering plans, SIP URI, and SIP URI with user=phone into the 
To-id information element is FFS. 

When the Code specific field, i.e., the bits 3, 2, and 1 of the octet number 1 is set to "001" it indicates that the To-id 
information element contains an E.164 number. When the To-id information element contains an international number 
(i.e. an E.164 number), the E.164 digit-string is included in the octet 3, octet 4, octet 5, etc. as shown in table 7.4.2.1.1, 
i.e., the Code specific field and the encoding of the E.164 digit-string included in the To-id information element is the 
same as for the From-id information element and specified in subclause 7.4.2.3 above. 



8 7 6 5 4 


3 2 1 


Octet 


Information Element code 
1 1 
1 1 


Code specific 


1 


Information Element length (in octets) 


2 
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Figure 7.4.2.7.1 : To-id information element 
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7.4.2.8 Replaces 

7.5 Session states and Session control procedures 

7.5.1 General 

This clause defines the basic session control states that an individual session may acquire. Since several sessions may 
exist simultaneously across the II interface and each session may be in a different state, the session states describe the 
state of a particular session rather then describing the state of the II interface. The procedures for session control are 
given in subclause 7.5.3. 

7.5.2 Session states 

7.5.2.1 Session originated by the ICS UE 

7.5.2.1 .1 Session states at ICS UE - ICS UE originated call 

This subclause lists the session states that may exist at the UE for a session originated by the ICS UE. 

null: No session exists. 

trying: This state exists for an UE originated session, when the ICS UE has requested a session establishment by 
sending an Illnvite message but has not yet received any response. 

proceeding: This state exists for an UE originated session when the ICS UE has received an II Progress 
message with Progress reason set to Call progressing from the SCC AS acknowledging that the SCC AS has 
received the II Invite message. 

alerted: This state exists for an UE originated session when the calling ICS UE has received an II Progress 
message with Progress reason set to Ringing indicating that remote endpoint alerting has been initiated. 

confirmed: This state exists for an UE originated session when the ICS UE has received an II Success message 
indicating that the remote endpoint has accepted the session. 

7.5.2.1 .2 Session states at SCC AS - ICS UE originated call 

This subclause lists the session states that may exist at the SCC AS for a session originated by the ICS UE. 

null: No session exists. 

initiated: This state exists for an UE originated session when the SCC AS has received an II Invite message but 
has not yet responded. 

progressing: This state exists for an UE originated session when the SCC AS has sent an II Progress message 
with Progress reason set to Call progressing acknowledging that the SCC AS has received the Illnvite message. 

alerting: This state exists for an UE originated session when the SCC AS has sent an II Progress message with 
Progress reason set to Ringing indicating that remote endpoint alerting has been initiated. 

confirmed: This state exists for an UE originated session when the SCC AS has sent an II Success message 
indicating that the call has been accepted. 

7.5.2.2 Session terminated at the ICS UE 
7.5.2.2.1 Session states at UE - ICS UE terminated call 

This subclause lists the session states that may exist in the UE for a session terminated at the ICS UE. 
null: No session exists. 
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initiated: This state exists for a session terminated at the UE when the ICS UE has received an Illnvite message 
but has not yet responded. 

progressing: This state exists for a session terminated at the UE when the ICS UE has sent an II Progress 
message with Progress reason set to Call progressing acknowledging that the ICS UE has received the Illnvite 
message. 

alerting: This state exists for a session terminated at the UE when the ICS UE has sent an II Progress message 
with Progress reason set to Ringing indicating that local alerting has been initiated but the offered call has not yet 
answered. 

confirmed: This state exists for a session terminated at the UE when the ICS UE has sent an II Success message 
indicating that the call has been accepted. 

7.5.2.2.2 Session states at SCC AS - ICS UE terminated session 

This subclause lists the session states that may exist in the UE for a session terminated at the ICS UE. 

null: No session exists. 

trying: This state exists for a session terminated at the ICS UE when the SCC AS has requested a session 
establishment by sending an II Invite message but has not yet received a response. 

proceeding: This state exists for a session terminated at the ICS UE when the SCC AS has received an II 
Progress message with Progress reason set to Call progressing from the UE acknowledging that the ICS UE has 
received the Illnvite message. 

alerted: This state exists for an UE terminated session when the SCC AS has received an II Progress message 
with Progress reason set to Ringing indicating that the UE has initiated local alerting. 

confirmed: This state exists for a session terminated at the UE when the SCC AS has received an II Success 
message indicating that the ICS UE has accepted the session. 

7.5.2.3 Session release 

7.5.2.3.1 Session states at ICS UE 

This subclause lists the session states that may exist at the UE for a session released either by the ICS UE or SCC AS. 

release-requested: This state exists when the ICS UE has requested the SCC AS to clear the session by sending 
an II Bye message and the CS bearer has not been cleared using receipt of a DISCONNECT message, in 
accordance with 3GPP TS 24.008 [3]. Upon determining that the CS bearer has cleared using a DISCONNECT 
message or determining that a II Success message was received, the UE transits to a "null" state. The ICS UE 
attempts to clear the CS bearer if a retransmission timer fires as specified in subclause 6.2.3. 1 .2. 

release-indication: This state exists when the ICS UE has received an II Bye message from the SCC AS 
requesting the UE to clear the session. Per subclause 6.2.3.1.2, upon subsequent clearing the CS bearer using a 
DISCONNECT message, in accordance with 3GPP TS 24.008 [3], or upon subsequent sending of an II Success 
message, the ICS UE transits to a "null" state. 

Editor" s Note: the name and length of the retransmission timer is FFS. 

7.5.2.3.2 Session states at SCC AS 

This subclause lists the session states that may exist at the SCC AS for a session released either by the ICS UE or SCC 
AS. 

release-requested: This state exists when the SCC AS has requested the ICS UE to clear the session by sending 
an II Bye message and the CS bearer has not been cleared. Upon determining that the CS bearer has cleared 
using a DISCONNECT message, in accordance with 3GPP TS 24.008 [3] and 3GPP TS 24.292 [5] or 
determining that a II Success message was received, the SCC AS transits to a "null" state. The SCC AS attempts 
to clear the CS bearer if a retransmission timer fires as specified in 3GPP TS 24.292 [5]. 
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release-indication: This state exists when the SCC AS has received an IlBye message from the ICS UE 
requesting the SCC AS to clear the session. Upon subsequent clearing the CS bearer using a SIP BYE request 
sent towards the MGCF or upon subsequent sending of an II Success message in accordance with 
3GPP TS 24.292 [5], the SCC AS transits to a "null" state. 

Editor" s Note: the name and length of the retransmission timer is FES. 

7.5.3 Session control procedures 

7.5.3.1 General 

Before the session establishment procedures are invoked, a transport-layer connection must be established between the 
ICS UE and the SCC AS. 

Editor"s Note: The II protocol message are self-identifying, i.e. the information contained in the II protocol 

message uniquely identifies the call to which the respective II protocol message pertains to. Hence, it is 
FFS whether the transport-layer connection may change during an established call or even while the call 
establishment and call release are in progress. 

7.5.3.2 Session establishment 

Editor"s Note: The II protocol error cases are not considered in this subclause. The II protocol error cases must be 
considered. 

7.5.3.2.1 UE-originating case 

7.5.3.2.1.1 Procedure at ICS UE 

7.5.3.2.1.1.1 Session request 

The ICS UE initiates session establishment procedure by sending an II Invite message to the SCC AS across the II 
interface. The II Invite message shall contain the II information elements as specified in subclause 6.2.1.2.1. Following 
the transmission of the II Invite message the session shall transit to the "trying" state. When the session enters the 
"trying" state, the ICS UE sets timer F to fire in T3 seconds. 

If an unreliable transport-layer connection between the ICS UE and the SCC AS is used, the ICS UE sets timer E to fire 
in Tl seconds. For reliable transport-layer connection timer E is not used. If timer E fires while the session is still in the 
"trying" state, the original II Invite message (with the same sequence number) is retransmitted and the timer E is reset 
to value of MIN(2*T1, T2). If the timer E fires again, the original II Invite message (with the same sequence number) is 
retransmitted again and the timer E is reset to a MIN (4*T1, T2). This process continues so that retransmissions occur 
with an exponentially increasing interval that caps at T2. 

Editor" s note: The values for Tl, T2 and T3 will be selected. 

If timer F fires while the session is still in the "trying" state, the call establishment has failed, and the ICS UE clears the 
session, as described in subclause 6.2.3. In addition, if an unreliable transport-layer connection between the UE and the 
SCC AS is used the, the ICS UE disables timer E. 

7.5.3.2.1 .1 .2 Session proceeding 

If an II Progress message with Progress reason set to Call progressing is received at the ICS UE while the session is in 
the "trying" state, the session shall transit to the "proceeding" state. 

If an unreliable transport-layer connection between the ICS UE and the SCC AS is used, when the session enters the 
"proceeding" state the ICS UE sets the timer E to fire in T2 seconds. If timer E fires while the session is in the 
"proceeding" state, the original II Invite message (with the same sequence number) is retransmitted and the timer E is 
reset to a value of T2 seconds. This process continues so that retransmissions of the original II Invite message occur 
every T2 seconds. 
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If timer F fires while the session is in the "proceeding" state, the session establishment has failed, and the ICS UE clears 
the call, as described in subclause 6.2.3. In addition, if an unreliable transport-layer connection between the ICS UE and 
the sec AS is used the, the ICS UE disables timer E. 

Upon receiving the II Progress message with Progress reason set to Call progressing from the SCC AS, the ICS UE 
initiates the setting up of the CS bearer connection toward the SCC AS by sending a SETUP message to the MSC 
Server as specified in subclause 6.2.1.2.1. 

NOTE: The request to set up the CS bearer connection arriving at the SCC AS indicates that the II Progress 
message with Progress reason set to Call progressing has been received by the UE. Subsequently, the 
SCC AS can progress the session toward the far end by sending a SIP INVITE request to the far end. 

7.5.3.2.1 .1 .3 Alerting indication 

If an II Progress message with Progress reason set to Ringing is received while the session is in the "proceeding" state, 
the session shall transit to the "alerted" state. 

If an unreliable transport-layer connection between the ICS UE and the SCC AS is used, when the session enters the 
"alerted" state the ICS UE sets timer E to fire in T2 seconds. If timer E fires while the session is in the "alerted" state, 
the original II Invite message (with the same sequence number) is retransmitted and the timer E is reset to a value of T2 
seconds. This process continues so that retransmissions of the original II Invite request occur every T2 seconds. 

If timer F fires while the session is in the "alerted" state, the session establishment has failed, and the ICS UE clears the 
call, as described in subclause 6.2.3. In addition, if an unreliable transport-layer connection between the ICS UE and the 
SCC AS is used, the ICS UE disables timer E. 

If the ICS UE receives an II Progress message with Progress reason set to Ringing, the ICS UE may begin a locally- 
generated alerting procedure. 

7.5.3.2.1 .1 .4 Session connected 

If an II Success message is received from the SCC AS while the session at the UE is either in the "proceeding" state or 
"alerted" state, the session shall transit to the "confirmed" state (i.e., the call has been established) and the timer F is 
disabled. 

If an unreliable transport-layer connection between the ICS UE and the SCC AS was used, the timer E is disabled, 
hence the ICS UE stops retransmitting the II Invite message. In addition, the ICS UE discards any subsequent II 
Success message, if it is received over the unreliable transport-layer connection. 

7.5.3.2.1 .2 Procedure at SCC AS 

7.5.3.2.1.2.1 Session request 

Upon receiving an II Invite message from the ICS UE over the II interface, the session at the SCC AS shall transit to 
the "initiated" state. Once in the "initiated" state, the SCC AS shall immediately respond by sending an II Progress 
message with Progress reason set to Call progressing to the UE and the session enters the "progressing" state. The II 
Progress message with Progress reason set to Call progressing shall contain the II information elements as specified in 
subclause 6.2.1.3.1. 

NOTE: The receipt of the II Progress message with Progress reason set to Call progressing at the UE, will trigger 
the UE to set up a CS bearer connection toward the SCC AS by sending a SETUP message to the MSC 
Server as specified in subclause 6.2.1.2.1. 

7.5.3.2.1.2.2 Session progressing 

If the SCC AS receives a retransmitted II Invite message from the ICS UE, while the call is in the "progressing" state, 
the SCC AS shall retransmit the previously sent II Progress message with Progress reason set to Call progressing to the 
ICS UE. 



£75/ 



3GPP TS 24.294 version 9.0.0 Release 9 41 ETSI TS 1 24 294 V9.0.0 (201 0-01 ) 

NOTE: The SCC AS receives a retransmitted II Invite message only if the transport-layer connection between the 
ICS UE and the SCC AS is an unreliable transport-layer connection. While the session is in the 
"progressing" state, the SCC AS may send to the ICS UE either an II Progress message with Progress 
reason set to Ringing, an II Success message indicating that the session has been accepted, or a new II 
Progress response with Progress reason set to Call progressing. 

If timer F fires while the session is in the "progressing" state, the session establishment has failed, and the SCC AS 
clears the session, as described in subclause 6.2.3. 

7.5.3.2.1.2.3 Alerting indication 

If the SCC AS sends an II Progress message with Progress reason set to Ringing to the ICS UE, the session state at the 
SCC AS shall transit to the "alerting" state. 

If the SCC AS receives a retransmitted II Invite message from the ICS UE, while the session is in the "alerting" state, 
the SCC AS shall retransmit the previously sent II Progress message with Progress reason set to Ringing to the ICS UE. 

NOTE: The SCC AS receives a retransmitted II Invite message only if the transport-layer connection between the 
UE and the SCC AS is an unreliable transport-layer connection. 

If timer F fires while the session is in the "alerting" state, the session establishment has failed, and the SCC AS clears 
the session, as described in subclause 6.2.3. 

7.5.3.2.1.2.4 Session connected 

If the SCC AS sends an II Success message to the ICS UE indicating that the session has been accepted, the session 
state at the SCC AS shall transit to the "confirmed" state. 

If an unreliable transport-layer connection between the UE and the SCC AS is used, when the session enters the 
"confirmed" state the SCC AS sets timer G to fire in (n*T2) seconds. For reliable transport-layer connection timer G is 
not used. If a retransmitted II Invite message is received while the timer G is running, the timer G is reset to fire in 
(n*T2) seconds, and the II Success message is retransmitted. The firing of the timer G indicates that the ICS UE has 
received the II Success message and the ICS UE has stopped the retransmission of the II Invite message. 

If timer G fires while the session is in the "confirmed" state, the timer F is disabled. 

If timer F fires while the session is in the "proceeding" state, the session establishment has failed, and the SCC AS 
resets timer G and clears the session, as described in subclause 6.2.3. 

7.5.3.2.2 UE-terminating case 

7.5.3.2.2.1 Procedure at ICS UE 

7.5.3.2.2.1.1 Session request 

Upon receiving an II Invite message from the SCC AS over the II interface, the session at the ICS UE shall transit to 
the "initiated" state. Once in the "initiated" state, the ICS UE shall immediately respond by sending an II Progress 
message with Progress reason set to Call progressing to the SCC AS and enter the "progressing" state. The II Progress 
message with Progress reason set to Call progressing shall contain the II information elements as specified in 
subclause 6.2.1.2.2. 

Editor"s Note: Whether the ICS UE, upon receiving an II Invite message from the SCC AS, may respond with 

either an II Progress message with Progress reason set to Ringing or an II Success message rather then 
with an II Progress message with Progress reason set to Call progressing is FES. 

NOTE: The receipt of the II Invite message at the UE will trigger the UE to set up a CS bearer connection toward 
the SCC AS by sending a SETUP message to the MSC Server as specified in subclause 6.2.1.2.1. 

When the session enters the "initiated" state, the ICS UE also sets timer F to fire in T3 seconds. 
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7.5.3.2.2.1.2 Session progressing 

If the ICS UE receives a retransmitted II Invite message from the SCC AS, while the session is in the "progressing" 
state, the ICS UE shall retransmits the previously sent II Progress message with Progress reason set to Call progressing 
to the UE. 

NOTE: The UE receives a retransmitted II Invite message only if the transport-layer connection between the UE 
and the SCC AS is an unreliable transport-layer connection. 

While the session is in the "progressing" state, the ICS UE may send to the SCC AS either an II Progress message with 
Progress reason set to Ringing, an II Success message indicating that the call has been accepted, or a new II Progress 
message with Progress reason set to Call progressing. 

If timer F fires while the session is in the "progressing" state, the session establishment has failed, and the ICS UE 
clears the call, as described in subclause 6.2.3. 

7.5.3.2.2.1.3 Alerting indication 

If the ICS UE sends an II Progress message with Progress reason set to Ringing, the session state at the ICS UE shall 
transit to the "alerting" state. 

If the ICS UE receives a retransmitted II Invite message from the SCC AS, while the session is in the "alerting" state, 
the ICS UE shall retransmit the previously sent II Progress message with Progress reason set to Ringing to the SCC AS. 

NOTE: The UE receive a retransmitted II Invite message only if the transport-layer connection between the UE 
and the SCC AS is an unreliable transport-layer connection. 

If timer F fires while the session is in the "alerting" state, the session establishment has failed, and the UE clears the 
session, as described in subclause 6.2.3. 

7.5.3.2.2.1.4 Session connected 

If the ICS UE sends an II Success message indicating that the session has been accepted, the session state at the UE 
transits to the "confirmed" state. 

If an unreliable transport-layer connection between the UE and the SCC AS is used, the ICS UE sets timer G to fire in 
(n*T2) seconds. For reliable transport-layer connection timer G is not used. If an II Invite message is received while the 
timer G is running, the timer G is reset to (n*T2) seconds, and the II Success message is retransmitted. The firing of the 
timer G indicates that the SCC AS has received the Success message and has stopped the retransmission of the II Invite 

message. 

If timer G fires while the session is in the "confirmed" state, the timer F is disabled. 

If timer F fires while the session is in the "confirmed" state, the session establishment has failed, and the ICS UE clears 
the session, as described in subclause 6.2.3. 

7.5.3.2.2.2 Procedure at SCC AS 

7.5.3.2.2.2.1 Session request 

The SCC AS initiates a session establishment procedure by sending an II Invite message to the UE across the II 
interface. The II Invite message shall contain the II information elements as specified in subclause 6.2.1.3.2. Following 
the transmission of the II Invite message the session shall transit to the "trying" state. When the session enters the 
"trying" state, the SCC AS sets timer F to fire in T3 seconds. 

If an unreliable transport-layer connection between the UE and the SCC AS is used, the SCC AS sets timer E to fire in 
Tl seconds. For reliable transport-layer connection timer E is not used. If timer E fires while the session is still in the 
"trying" state, the original II Invite message (with the same sequence number) is retransmitted and the timer E is reset 
to value of MIN(2*T1, T2). If the timer E fires again, the original II Invite message (with the same sequence number) is 
retransmitted again and the timer E is reset to a MIN (4*T1, T2). This process continues so that retransmissions occur 
with an exponentially increasing interval that caps at T2. 
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If timer F fires while the session is still in the "trying" state, the session establishment has failed, and the SCC AS clears 
the session, as described in subclause 6.2.3. In addition, if an unreliable transport-layer connection between the UE and 
the SCC AS is used, the SCC AS disables timer E. 

7.5.3.2.2.2.2 Call proceeding 

If an II Progress message with Progress reason set to Call progressing is received at the SCC AS while the session is in 
the "trying" state, the session shall transit to the "proceeding" state. 

If an unreliable transport-layer connection between the UE and the SCC AS is used, when the session enters the 
"proceeding" state the SCC AS sets timer E to fire in T2 seconds. If timer E fires while the session is in the 
"proceeding" state, the original II Invite message (with the same sequence number) is retransmitted and the timer E is 
reset to a value of T2 seconds. This process continues so that retransmissions of the original II Invite message occur 
every T2 seconds. 

If timer F fires while the session is in the "proceeding" state, the session establishment has failed, and the SCC AS 
clears the session, as described in subclause 6.2.3. In addition, if an unreliable transport-layer connection between the 
UE and the SCC AS is used, the SCC AS disables timer E. 

NOTE: The request to set up the CS bearer connection arriving at the SCC AS indicates that the II Invite message 
has been received by the UE. 

7.5.3.2.2.2.3 Alerting indication 

If an II Progress message with Progress reason set to Ringing is received while the session is in the "proceeding" state, 
the session shall transit to the "alerted" state. 

If an unreliable transport-layer connection between the UE and the SCC AS is used, when the session enters the 
"alerted" state the SCC AS sets timer E to fire in T2 seconds. If timer E fires while the session is in the "alerted" state, 
the original II Invite message (with the same sequence number) is retransmitted and the timer E is reset to a value of T2 
seconds. This process continues so that retransmissions of the original II Invite message occur every T2 seconds. 

If timer F fires while the session is in the "alerted" state, the session establishment has failed, and the SCC AS clears the 
session, as described in subclause 6.2.3. In addition, if an unreliable transport-layer connection between the UE and the 
SCC AS is used, the SCC AS disables timer E. 

7.5.3.2.2.2.4 Session connected 

If an II Success message is received from the ICS UE while the call at the SCC AS is either in the "proceeding" state or 
"alerted" state, the session shall transit to the "confirmed" state (i.e., the session has been established) and the timer F is 
disabled. 

If an unreliable transport-layer connection between the UE and the SCC AS was used, the timer E is disabled, hence the 
SCC AS stops retransmitting the II Invite message. In addition, the SCC AS discards any subsequent II Success 
message, if it is received over the unreliable transport-layer connection. 

7.5.3.3 11 service control signalling release 

7.5.3.3.1 Initiating release of II service control signalling 

The ICS UE or the SCC AS can release a II service control signalling session at any time irrespective of its state. The 
ICS UE or the SCC AS releases the II service control signalling session by sending an II Bye message across the II 
interface. The II Bye message shall contain the II information elements as specified in subclause 6.2.3. 

If an II Success message is received while the II service control signalling session is in the "release-requested" state, it 
transits to the "null" state (i.e., the II service control signalling session has been released). 

7.5.3.3.2 Responding to release of II service control signalling 

If either the ICS UE or the SCC AS receives an II Bye message across the II interface, the state of the II service 
control signalling session at the recipient side of the II Bye message (i.e. either at the ICS UE or the SCC AS) shall 
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transit to the "release-indication" state. If there are more II service control signalling sessions, once in the "release- 
indication" state, the recipient side of the II Bye message shall immediately respond by sending an II Success message. 

Editor's note: Either the ICS UE or the SCC AS may release the CS bearer connection when receiving a II Bye 

message by the UE sending a DISCONNECT message to the MSC Server or the SCC AS sending a SIP 
BYE request toward the MGCP, if there are no more II service control signalling sessions. Procedures for 
releasing the CS bearers when an II BYE message is received when there is one II service control 
signalling session remaining are FFS. 
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